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Telnet Remote Flow Control Option 
Status of This Memo 


This RFC specifies a standard for the Internet community. Hosts on 
the Internet that do remote flow control within the Telnet protocol 
are expected to adopt and implement this standard. Distribution of 
this memo is unlimited. 


Motivation 
This memo describes a method of remotely toggling flow control 


between a user telnet process and the attached terminal. Only flow 
control of data being transmitted from the telnet process to the 


terminal is considered. Many systems will also allow flow control of 


data from the terminal to the telnet process. However there is 
seldom need to change this behavior repeatedly during the session. 


There are two common ways of doing flow control: hardware and 
software. Hardware flow control uses signals on wires dedicated for 
this purpose. Software flow control uses one or two specific 
characters sent along the same path as normal input data. Most 
commonly, XOFF (control-S) and XON (control-Q) are used to stop and 
start output, respectively. The option described herein is useful 


primarily where software flow control is being used. (Since hardware 


flow control does not preempt any characters, there is normally no 
need to disable it.) 


The primary difficulty with software flow control is that it preempts 


one or two characters. Host software often requires the user to be 
able to input every possible ASCII character. (Certain editors are 
notorious for having XOFF and XON as commonly-used commands.) For 

this reason, operating systems often allow programs to disable flow 
control. While it is disabled, the characters that normally signal 
flow control may be read as normal input. In a telnet environment, 
flow control is normally done by the user telnet process, not by the 


host computer. Thus this RFC defines a way to propagate flow control 


status from the host computer to the user telnet process. 
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1. Command Name and Code 
TOGGLE-FLOW-CONTROL 
Code = 33 

2. Command Meanings 
IAC WILL TOGGLE-FLOW-CONTROL 


Sender is willing to enable and disable flow control upon 
command. 


IAC WON’ T TOGGLE-FLOW-CONTROL 
Sender refuses to enable and disable flow control. Nothing is 
implied about whether sender does or does not use flow control. 
It is simply unwilling to enable and disable it using this 
protocol. 


IAC DO TOGGLE-FLOW-CONTROL 


Sender is willing to send commands to enable and disable flow 
control. 


IAC DON’T TOGGLE-FLOW-CONTROL 


Sender refuses to send command to enable and disable flow 
control. 


IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE 


Sender requests receiver to disable flow control. The code for 
OFF is 0. 


IAC SB TOGGLE-FLOW-CONTROL ON IAC SE 


Sender requests receiver to enable flow control. The code for 
ON is 1. 


3. Default 
WON’ T TOGGLE-FLOW-CONTROL 


Flow control information will not be exchanged. 
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DON’T TOGGLE-FLOW-CONTROL 
Flow control information will not be exchanged. 
4. Description of the Option 


Use of the option requires two phases. In the first phase, the 
telnet processes agree that one of them will TOGGLE-FLOW-CONTROL. 
WILL and DO are used only in this first phase. In general there will 
be only one exchange of WILL and DO for a session. Subnegotiations 
must not be issued until DO and WILL have been exchanged. It is 
permissible for either side to turn off the option by sending a WONT 
or DONT. Should this happen, no more subnegotiations may be sent, 
unless the option is reenabled by another exchange of DO and WILL. 


Once the hosts have exchanged a WILL and a DO, the sender of the DO 
TOGGLE-FLOW-CONTROL is free to send subnegotiations to enable and 
disable flow control in the other process. Normally, the sender of 
the DO will be a host, and the other end will be a user telnet 
process, which is connected to a terminal. Thus the protocol is 
normally asymmetric. However it may be used in both directions 
without confusion should need for this arise. 


As soon as the DO and WILL have been exchanged, the sender of the 
WILL must enable flow control. This allows flow control to begin in 
a known state. Should the option be disabled by exchange of DONT and 
WONT, flow control may revert to an implementation-defined default 
state. It is not safe to assume that flow control will remain in the 
state requested by the most recent subnegotiation. 


Currently, only two command codes are defined for the 
subnegotiations: flow control off (code 0) and flow control on (code 
1). Neither of these codes requires any additional data. However it 
is possible that additional commands may be added. Thus 
subnegotiations having command codes other than 0 and 1 should be 
ignored. 
Here is an example of use of this option: 
Host1l: IAC DO TOGGLE-FLOW-CONTROL 
Host2: IAC WILL TOGGLE-FLOW-CONTROL 


(Hostl is now free to send commands to change flow control. 
Note that host2 must now have enabled flow control.) 
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Host1l: IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE 
Host1l: IAC SB TOGGLE-FLOW-CONTROL ON IAC SE 
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